A Shell namespace organizes a file system and other objects managed by the Shell into a tree-structured hierarchy. A namespace may include two basic types of objects: folders and files. Folders may be considered nodes of a tree-structure hierarchy, whereas, files the leaves of the tree-structured hierarchy. Today, when a user logs onto a computing device, a user profile is created wherein the user may store user specific information and configuration information for future use and keep it separated from other users logging onto the machine. The configuration information may include particular tool bar settings, screen resolution settings, and/or favorites.
In existing operation systems, such as Windows® brand XP Operating System, user profiles contain various known folders such as the My Documents folder or My Pictures folder. These known folders may provide access across multiple applications and computer network environments in order for developers and users to access information.
One drawback of current namespace configurations involves pollution of the namespace with a mixture of both application data and user data. Layouts of current namespaces do not provide for a clear separation between user data space and application data space. For example, FIG. 2 illustrates a prior art Shell namespace configuration 200 for an operating system such as Microsoft® Windows® XP. Referring to FIG. 2, a number of folders may be displayed wherein each folder belongs to one of four categories which include virtual folders, fixed file-system folders, common folders, and per-user folders.
Virtual folders may be virtual shell folders which appear in the shell namespace and may not have any actual file system folders associated with them. For example, a Printer folder may be a virtual folder. Fixed file folders may be file system folders that are not managed by the Shell and whose location is fixed when the system is installed. For example, the “Windows” folder 224 and the “Program Files” folder 220 may be fixed file folders. The common folders may be file system folders used for sharing data and settings between different users. For example, all users of a machine may share a common desktop folder such as desktop folder 202. Finally, per-user folders may be file system folders which are located under an individual's profile and owned by the individual user. For example, a My Pictures folder may illustrate a per-user folder for storing a user's pictures.
Referring to FIG. 2, the ultimate root of the namespace hierarchy 200 may be Desktop 202. Under the root Desktop 202, numerous other folders may be located such as My Computer folder 206, My Network Places folder 208, and Recycle Bin 210. The My Computer folder 206 may include various folders or mapped drives such as Local Disc (C:) 212, DVD-RW Drive (D:) 214 and Control Panel 216. Those skilled in the art will realize that numerous additional mapped drives and/or folders may be installed and listed in namespace hierarchy 200.
Local Disc (C:) 212 may include various additional folders and files such as Documents and Settings folder 218, Program Files folder 220, Uninstall folder 222, and WINDOWS folder 224. The Program Files folder 220 may contain various application programs that a developer or user may have installed on the particular computing device. The Uninstall folder 222 may provide utilities to assist a user in removing files and/or applications from the computing device. The WINDOWS folder 224 may contain various folder and files for use with a Windows® brand Operating System.
FIG. 2a illustrates a user profile namespace configuration for an operating system such as Microsoft® Windows® XP. Referring to FIG. 2a, an exemplary user profile namespace hierarchy 300 is illustrated. A Documents and Settings Folder 218 may include a number of folders and files such as an All Users folder 226 and multiple user's folders 228. For example, a user such as user George Kiessling may have a user folder identified by the user's name using a format such as “GKiessling.” As those skilled in the art will realize, each user may have their own user folder 228 to store particular information for an identified user. For instance, a user folder 228 may contain additional subfolders such as the My Documents folder 230, Desktop folder 280, Start Menu folder 282, Favorites folder 284, and other folders as illustrated in FIG. 2a. 
The My Documents folder 230 may be utilized as a default location for all documents created by a user. The My Documents folder 230 may comprise subfolders such as My Music folder 232, My Pictures folder 234, and My Videos folder 236. The My Music folder 232, My Pictures folder 234, and My Videos folder 236 may represent default locations wherein a user may store their music, pictures, and video data files.
A drawback of current namespace hierarchies is that current namespace hierarchies contain a mixture of both application program data and user data at the root of the namespace hierarchy. In current namespace hierarchies, there is no clean separation between application data and user data. The mixture of both application program data and user data is confusing for users and developers. For example, FIG. 2a illustrates the My Music folder 232, My Pictures folder 234, and the My Videos folder 236 under the My Documents Folder 230 even though these subfolders have little relevance to documents. In addition, a polluted namespace may lead to improper backup of files as users may be confused as to which files routinely should be saved.
Moreover, existing namespace hierarchies give little guidance to developers or application writers as to how applications should store per-user application data inside a user's profile. Further, there is little documentation as to how application developers should structure their folders within an application folder. As a result, application developers create new folders at the root of the namespace hierarchy further congesting the namespace.
Thus, it would be advancement in the art to provide a method and data structure which separates application data from user data in a namespace. The data structure would provide an intuitive profile layout for developers or users while supporting legacy applications. Furthermore, the method and data structure should enable a user to discover and utilize other public or users folders created by various applications which may be located on the same computing system or on a network with a minimal amount of effort.